Skip to content

Mesa Hostmot2 Xenomai4 OOB networking support#4199

Draft
hdiethelm wants to merge 3 commits into
LinuxCNC:masterfrom
hdiethelm:hm2_eth_oob_v5
Draft

Mesa Hostmot2 Xenomai4 OOB networking support#4199
hdiethelm wants to merge 3 commits into
LinuxCNC:masterfrom
hdiethelm:hm2_eth_oob_v5

Conversation

@hdiethelm

@hdiethelm hdiethelm commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

This PR adds Xenomai4 EVL out of band networking support for Mesa Hostmot2.

Out of band networking is basically a fast path inside the xenomai real time kernel that enables networking without involving the normal kernel.

Due to some users might want to use Xenomai4 with the standard kernel networking, I decided to create a new component called hm2_eth_evl while hm2_eth behaves exactly like before.

Common code is left in hm2_eth.c and network specific code is moved to hm2_eth_net.c and hm2_eth_net_evl.c.
The linker is used to link hm2_eth_evl and hm2_eth with two different network implementations and the same common code.

To select the mode, you can use: board_rtnet=posix or board_rtnet=evl, where the default is posix, so it is a non-breaking change.

A few changes in the existing code where performed:

  • Fix a bug in src/rtapi/uspace_xenomai_evl.cc. This resulted in a while(true) error message when the kernel and the userspace library did not match.
  • Pass board instead of board->fd to network functions.
  • Don't use a cumbersome void pointer casting one line function for SIOCSARP
  • The ifname is fetched in init_board() and stored in board, so the install_firewall_perinterface() loop is simplifyed and I can reuse the name inside the evl implementation
  • The ip address is stored in board because I need it later
  • Print which board is connected, nice if you have more than one board and it throws an error

Things still open:

  • I have to set the Xenomai4 C and LD flags to all modules, I did not find a way to only set it for a specific module in the Makefile. It will only change anything if you have libevl installed.
  • There are more global symbols. Would it make sense to rename fetch_hwaddr to hm2_fetch_hwaddr for example to avoid conflicts?
  • Loading hm2_eth_evl and hm2_eth at the same time would probably create a runtime linker issue which generates undefined behavior.

It's a bit hard to review due to moved code. git diff master:src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth_oob_v5:src/hal/drivers/mesa-hostmot2/hm2_eth_net_posix.c helps.

@hdiethelm

Copy link
Copy Markdown
Contributor Author

BTW: I know, rootless xenomai is still todo. I will do that after #4132 is in. It will conflict otherwhise.

@zz912

zz912 commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

@pcw-mesa What do you think aboat this PR? Do we want two drivers? hm2_eth.c and hm2_eth_net.c? Shouldnt be better implement OOB to hm2_eth.c?

To @hdiethelm : I can help with testing 7i96s.

@hdiethelm

Copy link
Copy Markdown
Contributor Author

@pcw-mesa What do you think aboat this PR? Do we want two drivers? hm2_eth.c and hm2_eth_net.c? Shouldnt be better implement OOB to hm2_eth.c?

This way, I can cleanly separate the two Ethernet implementations and not break the existing one by accident. Also hm2_eth.c is already quite big and I did not want to blow it up even more.

But you are right, having one module and instead using for example rt_eth_type=evl,posix,..., similar to board_ip=ip[,ip…​] would be an alternative and it would even allow to only use one xenomai capable network card if you have a second board that is not that important and connected to a non-xenomai capable NIC. I will look into it.

To @hdiethelm : I can help with testing 7i96s.

Thanks! I have also a 7i96s, this PR is already tested both with posix and evl networking. But a second test is always good to have, not all configs behave the same.

@zz912

zz912 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

But you are right, having one module and instead using for example rt_eth_type=evl,posix,..., similar to board_ip=ip[,ip…​] would be an alternative and it would even allow to only use one xenomai capable network card if you have a second board that is not that important and connected to a non-xenomai capable NIC. I will look into it.

This variant will be easier for switching "posix and evl". If you want evl to be used normally, you will need to add it to PNCconf. For most Mesa card users, installing a LinuxCNC distribution is the best they can do.

@zz912

zz912 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

ChatGPT is helping me with this PR. We have these questions:

Before I start preparing the environment, I have a few questions:

  1. Which Linux kernel version are you currently using for development and testing (e.g. 6.12.x)?
  2. Which Dovetail branch/tag or commit should be used with this PR?
  3. Which EVL version (or commit) do you recommend?
  4. Is there a reference build environment or set of repositories that you use, so testers can reproduce your setup as closely as possible?
  5. Which Ethernet drivers have you actually tested with the OOB implementation? Only igb, or also e1000e?
  6. Are there any known limitations or unsupported NICs at the moment?
  7. Is there anything specific you would like testers to measure or report (latency, jitter, missed frames, CPU load, etc.)?

@hdiethelm

Copy link
Copy Markdown
Contributor Author

You will find most information here:
#3878

For PREEMPT_RT, i use Debian Trixie, stock preempt kernel.

Intel I350 uses the igb driver. For e1000e, you need quite an old card.

If this fails, everything beaks and there are a thon of error messages.
So better abort here
Split into two network implementations, one for posix and
one for evl.

There are now two modules: hm2_eth and hm2_eth_evl.
@hdiethelm

Copy link
Copy Markdown
Contributor Author

So, I went back to having one component with two network backends:
Posix (Normal mode):

  • loadrt board_ip=192.168.1.121 config=...
  • loadrt board_ip=192.168.1.121 board_rtnet=posix config=...

Xenomai4 EVL mode:
loadrt board_ip=192.168.1.121 board_rtnet=evl config=...

Change back to one component that uses a "board_rtnet" argument to switch
between the types
@zz912

zz912 commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

I'm currently stuck on getting the EVL kernel working:
hdiethelm/xenomai4-linuxcnc#1
so I can't test anything yet.

The "board_rtnet" parameter looks good. Do you think it would be possible to add:
board_rtnet=auto
?
Would that make sense?

board_rtnet=evl - this configuration doesn't make sense when:
zdenek@cnc:~$ uname -a
Linux cnc 6.12.94+deb13-rt-amd64 #1 SMP PREEMPT_RT Debian 6.12.94-1 (2026-06-20) x86_64 GNU/Linux
?

board_rtnet=posix - does this configuration make sense when:
zdenek@cnc:~$ uname -a
Linux 6.12.85-cip22-xenomai4-efed61 #1 SMP PREEMPT_RT EVL
?

The less the user has to configure, the better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants